Smail is compiled with a default configuration. This default configuration is suitable for many sites that communicate to other systems via UUCP, or SMTP. For such sites, no configuration files are needed, though it may still be convenient to have a config file for attributes (described below) such as smart_user and smart_path. See the section DEFAULT CONFIGURATION for more details.
Comments begin with the character `#', in any column and end at the next newline. A `#' in the first column does not signify the end of an entry.
Variable and attribute names in configuration files are formed of characters from the set of letters, numbers and the character `_'.
String values may be enclosed in double quotes, in which case backslash escapes are processed as in C. If string values are not enclosed in double quotes, the values are limited to characters from the set of letters, digits and the characters ! @ $ % ^ & * - _ + ~ / ? | < > : [ ] { } . ' and `.
Numbers are as in C, with a prefix of 0 specifying an octal constant and a prefix of 0x specifying a hexadecimal constant. In addition, a suffix of k or K specifies a multiplier of 1024 and a suffix of m or M specifies a multipler of 1048576, or 1024K.
In addition to variables, a number of meta-expansions can be used. These expansions are of the form:
where meta_name defines some operation to perform on the value of the variable name. Multiple meta-expansions can be specified, and they are processed from right to left. For example:
This strips quotes from the value of the variable user and then converts characters to lower case.
When a string to be expanded begins with the character `~', a home directory is substituted. If only `~' is given, or `~/' is given, then the home directory associated with an address is substituted. If the form ``~username'' is given, where username is the name of a user on the local host, that user's home directory is substituted.
or
The first form includes string if the condition is true. The second form includes string1 if the condition is true, or string2 if the condition is false. For readability, else can be inserted before the else clause.
Possible conditions are:
or
Lookups operate by taking the value of the indicated variable as a key for lookup in a file. The proto string defines how the lookup is to be performed, and file-expansion is a string defining the file or database to search. If the key is found, then the found-string is expanded, otherwise the not-found-string is expanded. A $value reference in found-string is replaced by the value found by the lookup. For readability, then can be inserted before the found clause, and else can be inserted before the not-found clause.
Allowed lookup methods are:
In addition, the following variables are defined if they are available in the current context:
The following meta-expansions also exist:
The following are sample expansions:
/usr/spool/mail/${lc:user}
with a $user value of ``Tron'' will become:
/usr/spool/mail/tron
whereas:
Received: by $primary_name ($version_string)
id <$message_id@primary_name>;
$spool_date
will become something such as:
Received: by futatsu.uts.amdahl.com (smail 3.0.2 03-dec-87)
id <m0c87zK-007zXpC@futatsu.uts.amdahl.com>;
Tue, 8 Dec 87 19:45 PST
and:
$host!rmail ${strip:addr}
with an $addr value of ``Ronald S. Karr'' and a $host value of ``amdahl'' will become:
amdahl!rmail Ronald.S.Karr
If a value does not exist (such as $HOME being used when no associated home directory is known, or when a string begins with "~username" and the username is not known, or when $host is used for a local address) then the expansion fails.
variable_name or +variable_name
-variable_name
The first form above sets the variable to a string or numeric value, the second form sets a boolean variable, and the last form resets a boolean variable, clears a string value or sets a numeric value to zero.
The following config file specifies a spool file mode of 0400, a maximum message size of 200K, a method directory of /usr/lib/smail/method and disables use of a transport configuration:
# don't allow others to read spool files spool_mode = 0400 # truncate messages that are too large max_message_size = 200k # method files are stored in this directory method_dir = /usr/lib/smail/method # we are using the built in transport definitions, # so don't bother looking for a transport file -transport_file
The complete list of recognized attributes is given
in the following table,
in alphabetic order.
Note that the default values can be changed when
compiling the
smail
program.
This string will be expanded to form From: or Sender: fields. The
expanded string must begin with "From:", which may be replaced by
other strings to form an actual header field. The default value
is:
From: $sender${if def:sender_name: ($sender_name)}
The precedence names recognized by many BSD sendmail configurations are: special-delivery, first-class and junk. Others are useful mainly for getting mail out of the local machine or for communication with other machines running smail in a similar configuration. The grade character for a message is available in string expansions as the $grade variable.
NOTE: this value may be ignored in the future.
This string will be expanded to form the
Received:
header field.
This field will be inserted into the header
if the
received
attribute is not explicitly turned off
for a transport.
The default value for
received_field
is:
Received: \
${if def:sender_host\
{from $sender_host by $primary_name\
${if def:sender_proto: with $sender_proto}\
\n\t(Smail$version #$compile_num) }\
else{by $primary_name ${if def:sender_proto:with $sender_proto }\
(Smail$version #$compile_num)\n\t}}\
id $message_id; $spool_date
The maximum number of SMTP connections that smail will process at any
one time. This is for use with SMTP daemons started with the -bd
option to smail. If connection requests come in while when this
number of SMTP-connection children are forked, the connection will be
shutdown with SMTP message 421.
If this number of SMTP connection processes is exceeded, then additional
connections will be accepted, but their messages will be queued and will
not be processed until a later queue run. When the number of current
connection processes drops below this number, immediate mail processing
will resume, depending upon the value of delivery_mode.
This string will be expanded to form the SMTP startup banner that is
written by the SMTP server when a connection request is accepted.
Each line of this message is automatically preceded by a 220
identification code, and newlines are correctly changed into a
carriage-return newline sequence. The default value for
smtp_banner
is:
$primary_name Smail$version #$compile_num ready at $date
Each entry in one of these files specifies a name for the entry, a set of generic attributes and a set of driver attributes. The generic attributes and the driver attributes define the characteristics for the entry.
The list of possible generic attributes are common to all entries in a configuration file. One generic attribute is always required: the driver attribute. This attribute names the underlying set of functions that will be used when using that entry. The list of possible driver attributes are specific to different types of drivers.
The form of an entry is:
entry_name:
generic_attribute , ... ; driver_attribute , ...
where a comma separates the definitions for specific attributes and where a semicolon separates the generic attributes from the driver attributes. It is not an error for an entry to end in a comma or semicolon. The form for generic and driver attributes is the same as for entries in the config file.
As an example, consider an entry in the transport file that specifies use of the program /bin/mail to deliver mail to local users. The mail messages are to contain a ``Return-Path:'' header field, and the /bin/mail program is to be given no more than 20 addresses per invocation. A simple entry to specify this is:
# call /bin/mail to deliver to local users
local: max_addrs=20, return_path, driver=pipe;
cmd="/bin/mail $($user$)"
When smail is given a list of addresses to which a message is to be delivered, the list is processed iteratively until a list of resolved addresses is produced. When an address is resolved, the transport (the part of smail that performs delivery of messages to local users or remote hosts) and all data required by the transport will be known.
To accomplish this the smail program goes through the following steps:
When all addresses have been resolved, they are sorted out and passed to transports. It is the job of the transport to deliver a message to the set of addresses that it is given.
It is important to know that all hostnames and local usernames are matched independent of case, so that, for example, Postmaster, POSTMASTER and postmaster all compare equal. In addition an internal hash table is kept of all regular recipient addresses, that is, all addresses which do not specify files or shell commands. This table is used to discard duplicate regular recipient addresses. This hash table is independent of case, as well, so that the address Postmaster@SRI-NIC.ARPA is considered a duplicate of postmaster@sri-nic.arpa.
The following list describes the possible
generic attributes for director file entries:
If set then be cautious of addresses produced by this
director. If the nobody attribute is not
set, then reject file, shell command
or
:include:filename-style
mailing list addresses.
If the driver does not associate a group
to an address returned by it, then
associate the group id for this group
name. This will override the gid set by a
default_user
attribute.
If the driver does not associate a home
directory with an address returned by it,
then use this home directory.
The value will be expanded to form the actual directory pathname.
At the present time, the
$user
variable is not available for
this expansion.
If the string expansion fails,
it is ignored.
If the driver does not associate a user
or group to an address returned by it,
then associate the user id and group id
of this user.
The driver attribute names a specific set of low-level
functions which will do the work of directing
local mail. This attribute is required.
If set, then access files, or run shell
commands as the user specified
by the
nobody
attribute,
for
addresses flagged with
caution
by either the
caution
generic attribute or by the driver.
Association of nobody with an address
overrides the default_user,
default_group, set_user and set_group
attributes.
This attribute is set by default.
Names the address to be sent mail if an error
occurs in processing the addresses
produced by this director.
This string is expanded
with the variable
$user
set to the local-form
address passed to the director.
Commonly the value will be ``owner-$user''.
If this string expansion fails,
it is ignored.
If set, then it is always okay for this attribute to
produce an address equal to the sender.
This effectively turns on the
me too
flag for this director.
This should generally be set for
forwarding directors and should not be
set for aliasing and mailing list
directors.
Associate the gid for this group with the
addresses returned by the driver. This
overrides any gid set by the
set_user
attribute.
Associate this home directory with all
addresses returned by the driver. This
will be expanded in the same manner as
default_home.
Associate the uid and gid for this user
with addresses returned by the driver.
This overrides any values set by the driver.
There are two addresses which are required by the mailer software to exist: the address Postmaster and the address Mailer-Daemon. To avoid the necessity of an alias for these two users, smail contains two implicit directors embedded into the directing code. These implicit directors are used as a last resort. The first such director maps the address Mailer-Daemon onto the address Postmaster and the second maps Postmaster onto the address root.
The following list describes the possible
generic attributes for router file entries:
Routers will not always find a complete match for a particular
hostname.
For example,
if a routing database has a route to the domain
amdahl.com
but not to the hostname
futatsu.uts.amdahl.com
then the routing driver might return
the route to
amdahl.com.
Generally,
the route for the longest match of the target host
is used.
However,
if the
always
attribute is set,
then any match found by this router
will be used in preference to routes that might have been returned by
routers
later in the router list.
This is useful for hardwiring a certain number of
routes within a small database.
For example, this is useful for Internet sites that
gateway for a small number of UUCP sites
in the UUCP zone.
The driver attribute names a specific set of low-level
functions which will do the work of routing
remote mail. This attribute is required.
The router driver has the option of specifically setting a transport
to use for remote delivery.
If the driver does not do so,
then either a
method
or a
transport
attribute must exist to specify how the mail is to be delivered.
A
method
attribute specifies a file which contains a table relating
hostnames to transports.
A
transport
attribute specifies a specific transport.
If the method file does not contain a match for all hosts,
then the transport named with the
transport
attribute is used.
The format of a method file is given in the next section.
hostname transport-name
stating that mail being sent to hostname should be delivered using the transport transport-name. As a special case, if the hostname value is the special string ``*'', the entry matches any host. This is a catch-all feature which should only be used in the last entry in a method file.
Entries in a method file can be associated with particular message grades. This allows different grades to use different transports, such as non-demand UUCP for messages with a bulk or junk precedence. Grade ranges are specified by appending a grade letter range to the hostname, separated by /. Entries with grades can be in any of the forms:
hostname/X transport-name
hostname/X-* transport-name
hostname/*-Y transport-name
hostname/X-Y transport-name
See the definition of the grades configuration variable for a discussion of grade letters, and their correlation with message precedence strings. In the first form, the transport is used for an exact match of the grade letter. In the second form, a match requires a grade a character value of at least X. In the third, form a match requires a grade character value of at most Y. The final form specifies a range of grades from character value X to character value Y.
For example, with the default value for the grades variable, the following file will use smtp for hosts local1 and local2, if the precedence is air-mail or better; otherwise, for any host with a precedence of first-class or better, demand-polled uucp is used; otherwise, queued uucp is used:
local1/*-A smtp
local2/*-A smtp
*/*-C demand_uucp
* uucp
The following list describes the possible
generic attributes for transport file entries:
Use a batched SMTP format,
where the message is enclosed in an envelope of SMTP
commands.
This is not the same format commonly used on BITNET,
as it does not contain FORTRAN carriage control
characters.
This can be used to send mail to remote hosts using
SMTP formats even when direct two-way connections are
not feasible.
For example, this will work over UUCP and eliminates
difficulties with sending arbitrary addresses
as arguments to UUX.
Use of
bsmtp
also turns on the
dots
attribute.
When used with the
uucp
attribute, UUCP-style !-path addresses are used in the SMTP envelope.
If set,
then each line of the header and message
will end in carriage-return/line-feed rather than
a single newline character.
This is not typically useful,
as the SMTP transport,
which requires this as a part of the interactive protocol
always does this anyway.
If set,
replaces the body of the message
with debugging information. This can be
used, for example, as a shadow transport
to watch the flow of mail for a while for
debugging purposes. This essentially
allows for debugging without the ethical
and space problems of saving the
personal correspondence of others.
If set,
then use the hidden dot protocol.
All output lines which begin with dot will
have one more dot prepended.
All of the various SMTP modes imply this behavior.
The driver attribute names a specific set of low-level
functions which will do the work of delivering
mail. This attribute is always required.
names another transport that the message
should be sent to, if the first transport
returns failure.
If set,
then supply a ``From<space>'' line
before the message when delivering with
this transport.
If this is a remote transport
(i.e., the
local
attribute is not turned on)
then this line will end with ``remote from hostname''
where
hostname
is the UUCP name for the local host.
This is useful for delivery over UUCP and
for delivery to standard mailbox files,
which require this format.
``Half-baked'' batched SMTP.
This is batched SMTP mode without
an initial HELO command or an ending QUIT command.
This can be used for creating files which will be concatenated
together at a later time to form one batch of
SMTP commands containing multiple messages.
Use of the
hbsmtp
attribute also turns on the
dots
attribute.
If set,
the form of the header and envelope information will be setup for
delivery to the local host.
This performs no changes to existing header fields,
other than insertion of commas into fields containing
sender and recipient addresses.
This also affects the form of any generated
``From<space>''
line and the form of envelope addresses used
in SMTP commands.
This implies local_xform, but implies that delivery really is
final delivery to a user, file, or program on the local host. This
disables generation of a bounce message resulting from an
excessive message hop-count.
This states the maximum number of recipient addresses that can
be given in one call to the transport.
If this is turned off then there is no maximum number.
The default number is 1 and typically this is either
left as 1 or turned off.
This states the maximum number of characters in recipient addresses
that can be given in one call to the transport.
If this is turned off then there is no maximum number.
The default number is about one third of the number characters that
can be passed as arguments to a program.
When using SMTP transports this should be turned off unless a remote
host is known to be unable to handle a large number of addresses.
For delivery over UUCP to a remote
rmail
program,
this should be around 200 or 250,
to avoid buffer overruns at the remote site.
UUCP generally has small buffers to hold argument information.
This states the maximum number of different hosts that can be given
in one call to the transport.
If this is turned off, using the form
-max_hosts
then there is no maximum number.
The default number is 1 and typically this is
not changed.
If set,
then a
Received:
field is inserted for mail being delivered
with this transport.
The form of this field is taken from the
received_field
attribute in the
config
file.
This attribute is on be default.
If set,
then a
Return-Path:
field is inserted for mail being delivered
with this transport.
The form of this field is taken from the
return_path_field
attribute in the
config
file.
This should only be used for transports which
perform final delivery to local destinations.
This names another transport that the message
should be sent to. This could be used
to, for example, start a program that
looked up the sender in a database and
brought up a rendition of his face
from a
face server
in a
window on your workstation. The shadow
transport is called only if the
primary transport successfully performs
delivery.
If this flag is set,
then some effort is done to transform
mail which does not conform to RFC822 standards.
This is potentially useful for sites which gateway
between the UUCP zone and the Internet.
In general,
it is not a good idea to turn this on as it
changes the contents of headers fields.
This should only be done when it is known that
some remote hosts only understand
mail which conforms to the
RFC822 standard.
If set then any line in the body of the message which begins with
``From '' will have the character `>' inserted at the beginning.
This is required for local delivery to mailbox files that are in
the standard form expected by the System V
mailx (1)
and the BSD
Mail (1)
programs.
If set then outgoing recipient addresses will be converted
into UUCP-style paths of the form
hosta!hostb!hostc!user.
An exception is that any use of `%' as an address operator
is preserved.
Thus, an envelope address of
user%hostb@hosta
would be converted to
hosta!user%hostb.
This only affects envelope addresses and does NOT affect
the message or the message header.
If set then outgoing recipient addresses will be conform into to
internet specifications. This is not the same as the strict
attribute, since the transformations apply only to the envelope
addresses, and not to headers. If inet is defined, then
route-addr addresses will be generated when routing to remote
destinations, rather than !-style addresses. Thus, if smail is given
the address
user%host@gateway
and gateway is reached through the path
hosta!hostb!hostc,
then smail will generate the address
@hostb,@hostc:user%host@gateway
to be sent to the host @hosta.
The subdirectory under X_MAIL_SPOOL_DIR_X/retry to use for managing
host retry intervals for this transport. By default, the name of the
transport is used. However, multiple transports can share a retry
directory by setting retry_dir for several transports to the
same value. For example, by default all of the default TCP/IP SMTP
transports (inet_zone_smtp, uucp_zone_smtp, and
local_smtp set retry_dir to ``smtp''.
Identify a header field that will be removed from the message for
transport. This is an expansion string, so header removal can be made
dependent upon some conditions. If expansion of the string results in
an empty string, then no header is removed. Any number of
remove_header attributes can be specified.
Add the given header field at the beginning (insert_header)
or end (append_header) of the message header for transport.
These are expansion strings, so the header (and the existence of the
header) can be made dependent on some conditions. If expansion of the
string results in an empty string, then no header is added. Any
number of insert_header and append_header attributes can
be specified.
As an example of the manipulation of headers, consider the addition of an ``Organization'' header for all locally generated mail that does not already have an Organization header. This can be done with:
append_header="${if and{{origin:local}{!header:organization}} \
Organization: ACME Explosives Corp.}"
To configure a ``Content-Length'' field, which some systems use to identify the length of a message within a mailbox file rather than keying on lines starting with ``From'', use:
remove_header="Content-Length",
append_header="Content-Length: $body_size"
The qualify file defines the domain name(s) to be used in making all hostnames fully-qualified. Note that this file is used only for bare hostnames, i.e. names without dots.
The qualify file uses the standard routine for reading file entries. Each entry should have the form:
hostname domain
stating that the host name hostname should be considered a part of domain domain. As a special case, if the hostname value is the special string ``*'', the entry matches any host. This is a catch-all feature which should only be used in the last entry in a qualify file. Typically, UUCP sites should should have an entry like:
* uucp
at the end of the qualify file.
If the qualify file is missing, or if no entry is found that matches a given hostname, then no hostname qualification is performed.
The retry file defines, by target domain, the minimum interval between delivery attempts and/or the maximum duration over which to continue attempting delivery.
Each retry entry should have the form:
domain[:domain...] [interval]/[duration]
stating that, for the given domain(s), delivery will be attempted no more frequently than interval, and that delivery attempts will cease after duration.
Values for interval and duration are in seconds. However, they can be written as a sequence of numbers with suffixes of `s' for seconds, `m' for minutes, `h' for hours, `d' for days, `w' for weeks and `y' for years. For example, 10m/2d specifies an interval of ten minutes and a duration of two days.
Either or both of interval and duration may be omitted, in which case they are taken to be zero (i.e. no limit).
As a special case, if a retry file entry has a domain list equal to the special string ``*'', that entry matches any domain. This feature is a catch-all which should only be used in the last entry in a retry file.
If a retry file contains no ``*'' catch-all entry, then the configuration parameters retry_interval and retry_duration will be used to control retries to domains without specific retry entries.
A sendmail-compatible aliases file consists of relations between alias names and the lists of entities to that the aliases expand. Each entry is of the form:
alias-name: address, ...
The following is a sample alias file for a machine nsavax:
# Sample aliasing file for nsavax
root: brown, casey # redirect root's mail
MAILER-DAEMON: postmaster
postmaster: brown # brown maintains netnews and mail
netnews: brown
north: north, fawn # copy fawn on all north's mail
# post important information to network
msgs: local-msgs@ciacray, local-msgs@nscprofs,
local-msgs@nsavax
local-msgs: "|/usr/ucb/msgs -s"# deliver to msgs program
# administrivia
rnews: |/usr/lib/news/uurec# read news messages from mail
# mailing lists for accessing users on the local network
nsavax-users: :include:/usr/lib/mail/nsavax-users
ciacray-users: :include:/usr/lib/mail/ciacray-users
nscprofs-users: :include:/usr/lib/mail/nscprofs-users
# mail to everybody on the local network
everybody: nsavax-users, # well, almost everybody
ciacray-users,
nscprofs-users
# save mail to mailing list requests and send to moderator
funding-request: /usr/log/funding-req, reagan@nscprofs
covert-bugs-request: /usr/log/covert-bugs-req, james.bond@ciacray
# broadcast to mailing lists, and save a copy
funding: # excludes congress
:include:/usr/list/funding,
/usr/log/funding # save all messages here
covert-bugs: # includes kgb
:include:/usr/list/covert-bugs,
/usr/log/covert-bugs# save all messages here
The aliasfile driver searches for matches between a local address on input and an alias-name from the alias file. If a match is found, it returns the associated list.
It has the following driver attributes:
Define the name of the file containing the database. Except when this
is not appropriate for the
proto
being used, if this does not
begin with ``/'', it will be referenced relative to the
smail_lib_dir
directory.
A sleep interval between open retries, in seconds.
On systems which have 1 second granularities on wakeup
times and where, as a result,
sleep times can be nearly 0 seconds,
this number should be at least 2.
A mask, ala
umask(2),
defining the
maximum permissiveness allowed for the
permissions on the alias file. For example,
a modemask of 022 disallows write access
to all but the file owner. This value should be chosen to
strike a reasonable compromise between security and user
convenience. It should also take into account the use
of the
owners
and
owngroups
attributes described below. A paragraph below describes the
consequences for a file not meeting this criteria.
If set, then if the open fails, assume an empty
alias file.
This is useful for optional databases.
For example,
in a networking environment,
workstations may be configured with the option of having a private
alias file,
without the necessity of creating such a file on each host.
A list of permissible owners for the alias file. A paragraph below
describes the consequences for a file not meeting this criteria.
A list of permissible owning groups for the alias file. A paragraph
below describes the consequences for a file not meeting this criteria.
Names the protocol used in opening and searching the database.
Possibilities are discussed below.
If this attribute is on,
the alias file will be closed and reopened after
each call to the driver.
This is useful for systems that have a shortage
of file descriptors yet wish to access a large number
of databases.
the maximum count of open retries. This should
be greater than zero if the system does not
have an atomic rename(2) system call, as the
alias file may not always exist while being
modified.
If set, then if the open fails,
the resolution of local addresses will be attempted at a later time.
This is useful in a networking environment where failure
to open a database (such as a remote YP database) may be a result
of a server machine being down or temporarily inaccessible.
If any of the attributes modemask, owners or owngroups reject the file as a possible security problem, all addresses returned are flagged with the caution bit set. See the generic director attribute nobody for more information.
The current list of possible values for the proto attribute is:
where the domain_name: is optional and defaults to the default YP domain for the local host.
A simple entry in the director file is:
# don't perform any authentication on the alias file
aliases: driver=aliasfile;
file=/usr/lib/aliases, proto=dbm
address, address, ...
Where newlines can be included wherever whitespace is allowed, and where a `#' character begins a comment that ends at the end of the line. Comments are treated as whitespace.
An example forward file for the user james.bond on nsavax is:
# send to my own machine, but keep a copy here
# just in case it doesn't make it there.
bond%british-ss@ciacray, james.bond
A useful forward file is:
# I am on vacation, save away my mail, but tell people
# I won't be back for a while
hustead,
"|mailx -s 'Yep, gone fishing!' \"$SENDER\" < $HOME/.fish"
Which will save to Ted Hustead's mailbox file and will also execute the following shell command:
mailx -s 'Yep, gone fishing!' "$SENDER" < $HOME/.fish
where the shell variables $HOME and $SENDER are available from the environment as the user's home directory and the sender address, respectively. Note that if the ignore_write_errors attribute is not turned on in the pipe transport, this example will cause mail to be returned to the sender stating that a write error occurred on the pipe to mailx. To prevent this, the line could also be changed to:
"|cat>/dev/null;\
mailx -s 'Yep, gone fishing' \"$SENDER\"<$HOME/.fish"
where the ``cat>/dev/null'' will read stdin, preventing a write error on the pipe.
The current list of driver attributes for the forwardfile driver is:
This string defines a list of users
and directories which should cause
addresses to be flagged with
caution.
Each entry in the list is expanded individually.
If this string expansion fails,
it is ignored.
A number, or a number range (in the form
low_number-high_number) can be used to indicate numerical
uid's that should be treated with caution.
Typically,
this string is ``0'',
thus preventing file and shell command from
being performed as the superuser, ``0-99'', preventing access with a
system id.
If set, then one of the permissible
owners will be the user associated with the forward file.
The name of a file containing the forward
information for a user. This string will be expanded
with the local name
passed to the director available as
$user
and
any associated home directory available as
$HOME.
If this string expansion fails,
it is ignored.
If set, then the file must begin with
``Forward to '' to be considered a forward file.
Also, only the first line is scanned for addresses.
This ``feature'' mimics the capability found in
some systems for hiding forwarding information
in user mailboxes.
A mode mask defining the maximum permissiveness
allowed for the permissions on a forward file.
Analogous to the modemask attribute for the
aliasfile driver.
This attribute requires that an address begin with the specified
string to be matched by the director. In addition, any reference to
the
$user
variable in the file attribute will have this prefix removed.
This attribute requires that an address end with the specified string
to be matched by the director. In addition, any reference to the
$user
variable in the file attribute will have this suffix removed. Both a
prefix
and a
suffix
attribute can be specified for a director. In this case both the
prefix and the suffix string are required for a match.
Specifies a list of user who may own the
forward file.
Specifies a list of groups who may own the
forward file.
This string defines a list of users
and directories which should cause
addresses to be flagged with
unsecure.
This will prevent delivery to shell commands or files.
Each list entry is expanded.
If this string expansion fails,
it is ignored.
A number, or a number range (in the form
low_number-high_number) can be used to indicate numerical
uid's that should be treated with caution.
If none of the attributes owners, owngroups or checkowner is given, no checks are made on ownership restrictions. The default modemask is 0, effectively disabling checks for file mode restrictions.
The prefix and suffix attributes can be used to define mailing list directories associated with ownership or request addresses. To get a directory of mailing list or alias owners, a prefix of ``owner-'' could be used. To create a directory of request addresses, a suffix of ``-request'' could be used.
An example of useful forwardfile director entries are:
# put forwarding addresses for obsolete accounts under
# the /u/obsolete directory. These will contain only
# forwarding addresses. This is maintained by users in
# the group "admin" or "staff".
obsolete:
driver=forwardfile;
file=/u/obsolete/$user,
owngroups=admin:staff
# handle per-user forward files in each user's home
# directory. This is roughly compatible with BSD
# sendmail, though performs some access checks, and
# is very cautious of directories which are remotely
# accessible. Root's .forward entries will operate
# from the nobody uid.
dotforward:
driver=forwardfile, nobody;
file=~/.forward, unsecure=~uucp:~ftp,
caution=root, checkowner, owners=root,
modemask=022
# allow the "Forward to " feature to be used from user
# mailbox files as used in System V.
forwardto:
driver=forwardfile, nobody;
file=/usr/spool/mail/$user, caution=root,
checkowner, modemask=002
# define a mailing list directory, with any shell commands
# executed under the nobody user id. Any file in this
# directory defines the name and contents of a mailing list.
mailing_lists:
driver=forwardfile, caution;
file=/usr/lib/smail/lists/${lc:user}
# define a directory of owner mailing lists. Addresses
# specified in this directory specify the owner address of a
# mailing list or alias.
owner_lists:
driver=forwardfile, caution;
file=/usr/lib/smail/lists/owners/${lc:user},
prefix="owner-"
The format of a mailing list file is the same as that of a forward file, a simple list of addresses, with optional comments.
The driver attributes are common to both of the mailing-list
drivers:
If set,
attributes related to ownership restrictions
are taken from the director which produced
the mailing list address.
The modemask is copied from the director which
produced the mailing list address.
The sleep interval, in seconds, between retries. For systems that
have a 1 second timing granularity, this number must be at least 2 to
guarrantee a non-zero sleep interval.
Names the specific director that this
entry matches expansions of. This can be
used to assign different attributes from
alternate uses of the
aliasfile
and
forwardfile
directors.
The maximum permissiveness of file modes.
A list of allowed owners.
A list of allowed owning groups.
The maximum count of open retries.
The driver attributes are:
The prefix, if non-NULL, must be found in the front of the username
for this driver to be used.
This prefix is removed from the username prior to
determining if it is a valid user on the local host.
This can be used to set up an
alternate name for each user on the system
which is not matched by aliasing or forwarding
director. Commonly,
prefix
will be set to
``real-'' for one of the directors, so that
mail can be guaranteed to be delivered to a
user's mailbox file on a specific host by
mailing to an address such as
``real-tron@namei.uucp.''
If a match is found,
the actual username is given to the transport.
The name of the transport to associate with
the address.
A typical user director entry in the director file is:
user: driver=user; transport=local
This will associate any mail destined for a user on the local host with the local transport.
The possible driver attributes for the smart user driver are:
This defines the new address to direct mail
to. This string will be string expanded
with
$user
set to the
local address name, and with
$HOME
being any the associated home directory,
if there is one.
It is a configuration error for this
string expansion to fail.
If set, the
smartuser
driver only matches an address if it contains
characters exclusively from the set of
letters, digits, whitespace, as well as `-',
`_', `+', and `.'.
If the well_formed_only attribute is on, any use of $user in the new_user value will have any groups of one or more whitespace and dot are characters collapsed into exactly one dot. If it is off, the $user value may be enclosed in double-quotes, with backslash escapes where appropriate. This prevents the the value of $user from changing the form of the address.
A sample entry is:
smartuser:
driver=smartuser;
new_user=$user@gateway.domain,
well_formed_only
With this entry, the input addresses:
john and John Q. Public
will become:
john@gateway.domain
and John.Q.Public@gateway.domain
respectively. If well_formed_only had not been set, the second address would have been:
"John Q. Public"@gateway.domain
whereas the input address:
\unusual"address"in\deed
would become:
"\\unusual\"address\"in\\deed"@gateway.domain
Addresses which are produced by the smartuser driver are flagged as such and will not themselves be matched by the smartuser driver. Thus, infinite loops will not occur if ``gateway.domain,'' from the example, happens to be the local host.
It is possible to set the new_user value in the config file. This is done by setting the config file attribute smart_user. For example, the config file could contain the following line:
smart_user = $user@gateway.domain
Then, if the entry in the director file was:
smart_user: driver=smart_user; well_formed_only
the configuration would be equivalent to the second smart_user example above. This makes it possible to share copies of the director file among several machines, with the smart user configuration specific to one machine being set in its private configuration file. This config file attribute is used only if the new_user attribute is not given in the smart_user entry.
A list of domains to be stripped from the
end of a hostname before it is
searched for in the database.
Multiple
domains, in this list, are separated by colons.
This defines the name of the file containing
the database. Except when it does not make sense as a result of the
proto
used, if this does not begin with ``/'', it will be referenced
relative to the
smail_lib_dir
directory.
The number of seconds to wait between open retries.
If set, then if the open fails, assume an empty
alias file.
This is useful for optional databases.
For example,
in a networking environment,
workstations may be configured with the option of having a private
alias file,
without the necessity of creating such a file on each host.
Names the protocol used in opening and searching
the database. Possibilities are discussed
below.
If set,
the pathalias will be closed and
reopened after each call to the pathalias
driver. This is useful in
environments where file descriptors are
scarce but many databases are desired.
A list of domains which targets are
required to be for a match. The names
are not stripped, unless they are also
specified by the
domain
attribute.
The maximum number of retries for opening a
file. This is useful on systems without an
atomic rename system call. On such systems
there will be a window of vulnerability
when new databases are moved into place
where no file will exist.
A list of domains to be stripped only if
the target was not found in the database
without the domain stripped.
(This is currently not supported).
If set, then if the open fails,
the resolution of local addresses will be attempted at a later time.
This is useful in a networking environment where failure
to open a database (such as a remote YP database) may be a result
of a server machine being down or temporarily inaccessible.
The current list of possible values for the proto attribute is:
where the domain_name: is optional and defaults to the default YP domain for the local host.
All database lookups are either independent of case or, when case independent lookups are impossible, case-folded. Thus, keys in DBM or YP databases must be in lower case.
As an example of the use of the domain, try and required driver attributes, if the domain value is ``uucp,'' then any hostname that ends in .uucp will have the .uucp removed before being looked up. Alternately, if the the try value is ``uucp,'' then ``.uucp'' is stripped only if the original was not found. If the required value is ``uucp'' then a hostname is not a candidate for a match unless it ends in ``.uucp.'' The effects of domain and try are not cumulative and a hostname is applied to the required attribute value before being applied to domain and try in that order.
Note that the length of any stripped string is added to the count of characters matched for purposes of deciding which router had the most complete match.
A sample pathalias router entry is:
pathalias:
transport=uux, driver=pathalias;
file=paths, proto=bsearch,
domain=uucp
An example of a pathalias file for the site walldrug is:
.amdahl.com amdahl!%s
amdahl amdahl!%s
dgcad namei!glotz!nsavax!dgcad!%s
glotz namei!glotz!%s
hoptoad hoptoad!%s
kgbvax kgbvax!%s
kremvax kremvax!%s
namei namei!%s
nsavax namei!glotz!nsavax!%s
This data base associates a host or domain name, on the left hand side, with a path, on the right hand side. The right hand side should be a UUCP-style `!'-path ending in a ``%s''. The format is intended to be more general, with the ``%s'' showing where to put a user name. Indeed, pathalias(X_MAN8_EXT_X) can produce paths involving both right and left operators such as:
decwrl decwrl!%s@ucbvax
This form is not recommended in general because of a historical disagreement over the precedence of ``!'' and ``@'' which is not always resolved correctly by the pathalias program. By standardizing on UUCP-style `!'-paths, as will be produced from the USENET maps, we avoid many routing ambiguities. If the path is just ``%s,'' it denotes a name for the local host.
A simple driver that meets these requirements is the uuname driver, which reads a list of hostnames from the output of a shell command (normally /usr/bin/uuname) and uses this list to match neighboring hostnames.
An example entry for a site that wishes to route to their neighbors for hostnames that may end in .uucp is:
uuname: transport=uux, driver=uuname;
cmd=/usr/bin/uuname, domain=uucp
An alternative is a site that wishes to bypass the pathalias router only for explicit target matches, so that the form ``neighbor.UUCP'' will be routed through, as an example, pathalias. This can be done by not specifying a domain, as in:
uuname: transport=uux, driver=uuname; cmd=/usr/bin/uuname
The uuname driver also supports the domain, required and try attributes, and all three domain-style attributes can be colon separated lists. See the pathalias driver for more details on these attributes.
In addition, there is a string attribute, statfile which names a file which can be used to determine when the output of the shell command will change. For example, when used with the uuname command this would normally be either /usr/lib/uucp/L.sys or /usr/lib/uucp/Systems depending on whether a site is using HoneyDanBer or stock V7-style UUCP. If a statfile attribute is defined, then smail daemons that expect to deliver multiple messages will cache the output of the shell command. The specified pathname will then be checked at regular intervals to determine if the command should be reissued to refresh the cached information.
The queryprogram driver supports the domain, required and try attributes, as defined in the description of the pathalias driver. The program and its arguments are described in terms of a cmd attribute which is a string consisting of white-space-separated tokens which are expanded to form a program name and the arguments to pass to that program. The variable $host can be used to obtain the target host string. White space or punctuation from an expansion variable do not delimit arguments. Two additional boolean attributes affect the driver's behavior:
A trivial example of the use of this driver is the router file entry:
match_bar:
driver=queryprogram, transport=bar;
cmd="/bin/test X${lc:host} = Xfoo"
This router will use the program test(1) to determine if the target host is foo. If this is the target host, then it is assumed to be a neighboring host which can be reached over the transport bar.
A more complex example is to create a shell script such as:
# match_fubar.sh - match hosts on the fubar networks
case "$1" in
foo) echo "foo foo_transport"; exit 0;;
bar) echo "foo!bar foo_transport"; exit 0;;
curds) echo "curds curds_transport"; exit 0;;
whey) echo "curds!whey curds_transport"; exit 0;;
esac
exit 1
By setting up a router file entry such as:
match_fubar:
driver=queryprogram;
cmd="/bin/sh $lib_dir/match_fubar.sh ${lc:host}",
read_path, read_transport
a complete, though not particularly optimal, router is created which can match the hosts foo, bar, curds and whey and cause messages to these hosts to be delivered using one of the transports foo_transport or curds_transport.
The queryprogram driver is not very efficient, as it requires a fork/exec for each host. However, it is a very simple to construct a new router using this driver, so it is useful for prototyping. In general, a new form of routing requirement is most efficiently handled by writing a new router driver.
Additional attributes are:
Do not match hosts that have a domain component (i.e., that contain a
dot). The domain attribute is applied before the
only_local_domain attribute, so hosts that have a domain component
consisting only of one of the strings listed with the domain
attribute can be matched.
gethostbyname will only match a target host completely. The hostname given to the transport will be the host as given by the h_name field of the hostent structure.
The gethostbyaddr driver matches targets of this form, which is defined by square brackets surrounding only digits and dot characters. The driver then converts this number into a hostname by calling gethostbyaddr(3N) to determine the proper name for the host. If gethostbyaddr fails, then the input domain literal name is given to the transport. This is useful with incomplete host tables.
The gethostbyaddr driver has the following attributes:
If set, see if the hostname
returned by gethostbyaddr() matches
one of the known names for the
local host. The name ``localhost''
is counted here as a potential name
for the local host.
NOTE: This attribute is set by default.
If set, then any domain-literal
target which does not fit the form
of an internet address is
considered an error. If not set,
then such addresses are merely not
matched by the driver.
The following attributes vary the behavior of the
bind
driver:
If this boolean attribute is set, then we must be able to connect to
the server. If attempts to connect to the server fail, then routing
is retried at a later time, on the assumption that the nameserver is
only down temporarily. If this attribute is not set, then a failure
to connect to the server will cause the router to be ignored. This
allows a bind router to be optional based on whether or not the server
exists.
NOTE: This attribute is set by default.
If this boolean attribute is not set, then it is considered an error
for an MX resource record to be encountered which points to the local
host. If this attribute is set, then such an MX resource record will
cause the address not to be matched. The precedence number for the
resource record is taken into account here, so that an MX resource
record which points to the local host is ignored if there are other
records with a lower precedence number.
This boolean attribute is passed to the BIND resolve routines as the
RES_DEFNAMES flag. If set, then hostnames which do not contain dots
will have a default domain appended to them before lookups. For
example, this allows for hosts on a local area network to be
referenced using the basename of the host rather than requiring the
full domain name.
NOTE: This attribute is set by default.
If this string is set, then it is used as a colon-separated list of
domain names. If a hostname ends in any of these domains, then the
router will not match the host, and will not result in any queries.
This can be set to a list of domains that are known not to exist, such
as uucp and bitnet, to prevent expensive lookups which
will never be successful.
If this boolean attribute is set, then a hostname with only one domain
component (i.e., no dots) will not be matched. This should probably
be set if defnames is not set, to prevent lookups for uucp
hostnames that will not be found by BIND.
If this boolean attribute is set, then match a host only if it has an
MX record. This is not currently useful on the Internet as a whole,
though it does have uses in managing networks disconnected from the
Internet, but that use BIND to manage the hostname space. If all
hosts that can accept mail have an MX entry pointing to them, then no
attempts will made to send mail to other ``hosts,'' such as printers
or terminal concentrators.
A list of gateways and corresponding domains for explicit routing using the
bind processing logic for the gateway address. The string consists of a
sequence of lists. Each list consists of strings separated by colons, and
the lists are separated by a string consisting of a single `+' character.
Each list consists of the name of a gateway, followed by a list of domains
that should be routed to that gateway. The gatewayed domains will match
either against a complete address, or against the terminating domain of an
address. For example:
In this example, if an address of the form <anything>.uucp is being
processed, it will be converted to uknet.ac.uk before any other processing
is done. The new name will then be looked up in the DNS and routed
accordingly. Thus mail for <anything>.uucp will always be sent to
uknet.ac.uk, by whatever route is registered in the DNS for that address.
Similarly, mail for the domains bitnet, ie, and earn will be routed to
earn-relay.ac.uk.
A list of domains, separated by colons, to be tacked onto the end of the
address if it isn't found directly in the DNS. For example:
With this setting, an address such as "psy.ox" will first be tried as it stands, then "psy.ox.cam.ac.uk" will be tried, and if that fails, "psy.ox.ac.uk" will be tried.
The following attributes are for use in the UK, where mail routing is
complicated by the co-existence of both the Internet and the JANET mail
protocols.
If this attribute is set, then an address which is matched in the DNS but
which does not have any usable MX records because they have been discarded
for UK-specific reasons (see below) will be routed to this transport,
provided the address ends in `.uk'. The string should be the name of a
transport defined in smail's transports configuration file.
If this switch is set, addresses that are sent to the greybook transport
are left in world order, otherwise they are inverted into UK order.
A list of known gateways which are not to be used for sending SMTP mail
within the UK (that is, to addresses that end in `.uk'). For example:
The highest MX precedence value that is acceptable for an address in the
UK for SMTP mail. The default value is 999, which disables this option, but
sites in the UK should normally set it to 9 in accordance with the
established convention that preference values greater than 9 should not be
used for intra-UK SMTP mail.
If this attribute is set, then when an address cannot be found in the DNS,
even after widening with the strings given in the widen_domains attribute,
the original address is inverted (e.g. uk.ac.somewhere becomes
somewhere.ac.uk) and the whole process is tried again. Inversion does not
take place if the address already ends in `.uk'.
All matches found by the bind driver are considered full matches, for the purposes of prioritizing results from different routers. Matches are considered full even in the presence of wildcards in MX records.
A site which exists only on the internet, requiring no other means of routing should have a router file consisting of the entries:
# match internet address domain literals
internet_addrs:
driver=gethostbyaddr, transport=smtp;
fail_if_error
# match internet hostnames
internet_hosts:
driver=bind, transport=smtp
A site which servers as the internet gateway for some set of hosts should either have a paths file naming the hosts for which it gateways, or should use the local_mx_okay attribute and allow target hostnames to fall through to a router for another network. For example, a UUCP network gateway which gateways for a set of hosts listed int the UUCP map database distributed over USENET could use the following two routers, in order, to handle all of its gateway responsibilities:
internet_hosts:
driver=bind, transport=smtp;
local_mx_okay
uucp_hosts:
driver=pathalias, transport=uux;
file=/usr/lib/smail/paths
If the defer_no_connect is not used, then it is advisable to include a gethostbyname router to match hostnames. The following sequence of routers will allow the same smail configuration to be used on machines that do have the BIND server and on machines that don't have the server:
internet_hosts:
driver=bind, transport=smtp;
-defer_no_connect
network_hosts:
driver=gethostbyname, transport=smtp
The smarthost driver has the following driver attribute:
This define a host or UUCP-style `!'-path path that defines
the smart host.
If no transport or method attribute is given for the router file entry, this address will be resent through all the routing drivers. An exception is that an address cannot be sent to the smarthost driver twice, as this would mean that the path to the smarthost was not known.
The global configuration variable auth_domains affects the smarthost router by restricting the set of hostnames that can be matched by the smarthost router to hostnames that are outside of the domains listed in auth_domains.
For example, if the site namei wanted to use amdahl's routing database for mail delivery to non-neighboring sites they could use a router file entry of:
smart_host: driver=smarthost; path=amdahl
or smart_host: transport=uusmtp, driver=smarthost;
path=amdahl
Then, a recipient address of ``Ted.Husted.Jr@walldrug.uucp'' will be rewritten so that the hostname is amdahl and the remaining part of the address is ``Ted.Hustead.Jr@walldrug.uucp.'' Alternately, in the second form for the entry, the transport, uux, would be known immediately and be passed the hostname ``amdahl'' immediately, with a $user value of ``Ted.Hustead.Jr@walldrug.uucp.''
By specifying a UUCP-style `!'-path it is possible to route mail to a smart host that you would not otherwise be able to route to. For example, if the machine glotz wished to use amdahl as its smart host, through its neighboring site namei, it could use:
smart_host: driver=smarthost; path=namei!amdahl
or smart_host: transport=demand, driver=smarthost;
path=namei!amdahl
It is possible to set the path and/or the transport in the config file. This is done by setting the config file attributes smart_path and smart_transport. For example, the config file could contain the following:
smart_path = amdahl
smart_transport = uusmtp
Then, if the entry in the router file was:
smart_host: driver=smarthost
the configuration would be essentially the same as in the second smart_host example above. This makes it possible to share copies of the router file among several machines, with the smart host configuration specific to one machine being set in its private configuration file.
These config file attributes are used only if the path driver attribute is not given in the smart_host entry. If the smart_path attribute from the config file is used, the smart_transport will override a transport or method attribute.
host1!host2!host3!host4!host!user
The rerouter driver could realize that a more efficient path exists to host and rewrite this as:
host6!host!user
Before you say to yourself how neat this would be and how much of a savings this would be for the world, you must realize that such rerouting is dangerous and should be configured-in only with a great deal of consideration and attention to detail in your rerouting database.
Here are the attributes supported by the rerouter driver:
An expansion string defining a file that selects which hosts or
domains will be considered candidates for rerouting. If the string,
after expansion, does not begin with /, it will be opened
relative to the smail library directory. The format of the file is
described later in this section.
The lookup protocol to use in searching through the database specified
by the file attribute. The list of possible lookup protocols
for the rerouter driver is the same as for the pathalias driver.
A colon-separated list of default domains for hosts in the database.
Targets ending in any of these domains will have the domain stripped
(incuding a preceding dot) before the database is searched. A target
containing only the domain (e.g., just .uucp) will remain
unchanged.
A colon-separated list of domain names that are must be part of a
hostname for that hostname to be considered a candidate for rerouting.
If set, then reopen the database for each call to the rerouting
driver, and close before each return. This is necessary for systems
that would not otherwise have a sufficient number of available file
descriptors for all of their routing and directing needs.
if set, then if the open of the database file fails, assume an empty
file.
if set, then if the open fails, try again on a later spool directory
queue run.
If set, reroute all bang path addresses. The rerouting database isn't
used at all in this mode, so even hosts that have an exclusion flag
(`-') in the database will be rerouted. Use this only for
debugging purposes. Unconditional rerouting is an offense against the
net.community!
If set, then address containing forms for the local host (within the
bounds of the required attributes) are considered candidates for
rerouting. The path starting with the component directly following
the last occurance of the local hostname is used rerouting. For
example, if the local hostname is geminix, then the input path:
host1!host2!geminix!host!user
host4!host!user
If set, a database lookup is done for the target. Otherwise, the
reroute database isn't used. This must be set of you intend to set
the file attribute to point to a database.
This attribute combines with the matchlocal attribute to do
limited rerouting that bypasses multiple occurances of the local host,
but only for bounce messages (messages generated for returning errors
to the originator of a message). This attribute affects only the use
of the matchlocal attribute, and has no other affect on the
rerouter driver.
The rerouter driver operates only on pure !-path addresses. For such addresses, the !-path is scanned from right to left for hostnames that are considered candidates for rerouting. If such a host is found, the path is truncated to contain everything from that component to the end of the path. In the case of a match resulting from the matchlocal attribute, the matching component is also removed from the path.
Given a truncated path generated by the rerouter driver, the address is passed back into the smail address resolver engine to be rerouted based on the other routers. This goes all the way back to the beginning of the address resolution process, rather than continuing on with the list of routers, as would happen for a non-matching target hostname.
If a database file is used to define candidate hosts for rerouting, the file will be presumed to contain entries consisting of a hostname or a domain name beginning with a period, followed by + or -. For example, the database file might contain:
.do.main + .bar + .foo.bar - host1.foo.bar + host2 + host2.abc + host3 + host4 +
If a match is found on the given hostname, then the + or - is used to indicate whether the hostname is a candidate for rerouting. A + indicates that the host is a candidate, a - indicates that the host is not a candidate.
The rules for finding an entry in the database are:
This lookup algorithm, together with the + or - field can be used to enable rerouting for all but a certain subset of hosts within a domain.
However, before you enable rerouting you should make sure that your routing databases are really accurate. It's not enough that you install the posted USENET maps automatically. These maps are notoriously inaccurate, and often contain very unrealistic link costs, resulting in non-optimal routes. Therefore, it is necessary to check all routes that might be used for rerouting line by line whenever it is rebuilt from the maps.
If you can't or don't want to do this, don't use rerouting! Or at least only for sites in your direct neighbourhood. Rerouting with a poorly maintained routing database is a disservice to the net! The simplest way to setup rerouting is to limit the set of hosts that you use for rerouting and ensure that the routes to all of those hosts are stable and accurate. Making a separate paths file-based router is the simplest way of ensuring that stable paths are used.
Also, if you think that you have the administrative resources for rerouting, do so only when you are willing to keep in touch with the maintainers of other rerouting sites in your area. Mail loops between two rerouting sites are a serious problem that can be reduced only by discussing changes you want to make to your routing in advance.
So in short, folks, don't use rerouting if it isn't absolutely necessary. Please don't use it as a means to inflate your ego. Instead, maintaining a rerouting host is a responsible task that needs lots of time and determination. Please restrain yourself, for the sake of fast and flawless mail delivery.
The only safe way to reroute an address is to reroute from left to right rather than right to left, and to stop as soon as a host is found which is not a rerouting candidate. However, such a policy greatly limits the usefulness of rerouting or at least it greatly increases the number of entries in your rerouting database that are necessary for rerouting to be useful.
The driver attributes for the pipe
driver are:
The program to be run and the arguments
to be passed.
This is string expanded.
To handle multiple addresses being given
to a transport,
the use of
$(
and
$)
can be used to bracket a section of the
command string which is to be repeated for
each address given to the transport.
It is a configuration error for string expansion
to fail.
Generally, only child failures from
the signal SIGTERM are reattempted
at a later time.
If this
is set, then retries are performed at a later time if the
exit code is non-zero, or if the write
failed on the pipe.
This is useful for treating errors from
UUCP as configuration or as
temporary filespace problems.
The name of the group to
setgid(2)
to within
the child process. Useful only if the
mailer is running as root.
If set, the exit status of the child process is
ignored. If this is not set, an exit
value other than 0 is noted and mail is
sent to the postmaster stating this.
If set, write errors are ignored. This
is useful for running programs that may
not actually read their standard input.
If this is not set, a write error will
cause mail to be returned to the sender.
The
stdout
and
stderr
of a command are
logged and returned to the sender in case
of problems.
The current implementation is not very good
as it actually returns the logs for all such transports
in the event that any transports fail.
This attribute is on by default.
Stuff the environment with data taken
from the parent of the input address,
rather than the input address itself.
This is useful for the
transport specifically named
pipe
which is used by smail for delivery
to shell-command
addresses.
Here the recipient address stored into
the environment will then be the address
that produced the
shell-command address,
rather than the shell-command address itself.
If set, the child process' uid is taken
from the real uid at the time the message was
read by
smail.
This does not affect the
group id for the child. This overrides
the uid obtained from the
pipe_as_user
attribute.
Obtain a
uid
and,
if `group' attribute is not given,
a
gid
associated with the
address (such as the user for a .forward file).
Then set these via
setuid(2)
and
setgid(2)
in the child process.
NOTE: This attribute is on by default.
file creation mask for the child process.
The name of the user to
setuid(2)
to within
the child process. Useful only if the
mailer is running as root.
The environment of the child process is entirely initialized and loaded with variables which may be useful in shell scripts or intelligent mail processing programs. Exactly one environment variable is passed through from the environment handed to the smail program: the TZ variable defining the timezone. The following portion of the environment is independent of the recipient addresses:
BASENAME the basename for the spool file GRADE the grade character MESSAGE_ID the message ID as assigned by smail PATH ``/bin:/usr/bin'' PRIMARY_NAME the official name for the host SENDER the sender address SHELL ``/bin/sh'' SPOOL_FILE the complete name for the spool file UUCP_NAME the name for the host on the uucp network VISIBLE_NAME the name for the host used in addresses
The rest of the environment is loaded from the input address, or from the parent of the input address:
Examples of the use of the pipe driver are:
# transport used for delivery to shell-command addresses
pipe: from, local, return_path, unix_from_hack,
driver=pipe;
cmd="/bin/sh -c $user",
pipe_as_user, ignore_status,
ignore_write_errors, parent_env,
-log_output
# delivery to a remote rmail(8) program using uux(1)
uux: max_addrs=5, max_chars=200, from, received,
driver=pipe;
cmd="/usr/bin/uux - -r -g$grade $host!rmail
$((${strip:user})$)", # see ``String expansion'' above
pipe_as_sender
The driver-specific attributes are:
Get the
uid
and, perhaps, the
gid
from
the user id and group id associated with
the address.
For example, the user
associated with a forward file
might be used.
This attribute is on by default.
If set, then verify the permissions on a
complete path for a file or dir attribute.
This requires that all directories leading
to a file must be searchable by the
appending user (see the
user,
group
and
append_as_user
attributes).
Under System V,
this requires a
stat(2)
call for each
directory in the path, and is thus somewhat expensive.
Reject an address if the
$user
would contain a `/'.
This prevents a
$user
expansion
from accessing a different directory.
Defines a directory in which to write
unique files. Files written to this
directory always begin with the letter `q',
while temporary files used in the creation
process begin with ``temp.'' This string is
expanded similarly to the
file
attribute.
It is a configuration error for this string expansion
to fail.
If set the value for
$user
value is string expanded
before the value for the
file
or
dir
attribute is expanded.
This is useful if a local-form address may
require
`~' or `$' expansions.
Defines a file to append messages to.
This string is expanded,
and the variables
$user
and
$host
are set
from the recipient address.
It is a configuration error for this string expansion
to fail.
become this group. Similar to the
user
attribute.
When creating a file,
creat(2)
it with this access mode.
The default is 0666.
Notify the COMSAT daemon of the message delivery, so that users can
be notified that they received mail. This has no effect if your system
does not support the COMSAT daemon. This should be used for delivery
to user mailbox files.
This prefix is inserted in the file
before the message. This string is
expanded, with
$user
and
$host
being available from the
recipient address.
It is a configuration error for this string expansion
to fail.
This suffix is appended to the file after
the message.
This string is expanded, with
$user
and
$host
being available from the recipient
address.
It is a configuration error for this string expansion
to fail.
This become this user (effectively at least)
when opening or creating the file. Access
permissions are checked relative to this
user, and the user will own the file if it
did not previously exist.
To better understand the use of some of these attributes, consider the transport file entry:
file: driver=appendfile, from, return_path, local;
file=$user, suffix="\n", check_path,
expand_user, append_as_user, mode=0664
This transport will be called when a file address is produced by a director. Such addresses should be expanded, because they may require `~' expansions. Also, to keep standard many user agents happy, an extra newline is inserted after each message. The append_as_user attribute is set to ensure that addresses produced from, say, a forward file are only created or appended to if the associated user has permissions to do so. Because these filenames can be arbitrary, check_path is set to make sure that an otherwise inaccessible directory is not written to.
When given an address of ``~/Incoming,'' with an associated home directory of ``/u/joe-user'' and an associated user of joe-user, the following steps occur:
Next, lets examine:
local: driver=appendfile, local, from, return_path;
file=/usr/spool/mail/$user, append_as_user,
check_user, mode=0600, notify_comsat
In this example, the $user value is not expanded before expanding the file attribute. Also, just to make sure, $user is verified to not contain a `/'. Given an input address of ``jane-doe,'' associated with the user jane-doe, mail will be appended to the file ``/usr/spool/mail/jane-doe.'' If it did not previously exist, it will be owned by jane-doe and will have a mode of 0600.
The smtp driver can be used for delivery of any number of addresses to one remote host, where the remote host can be specified either in form of a hostname known by the networking software or by an internet number in square brackets, such as [192.2.12.142]. For example, the routing drivers gethostbyaddr and gethostbyname are suitable for matching addresses to be delivered using the SMTP driver.
The attributes for the tcpsmtp driver are:
This defines the response timeout for oerations that are assumed to
be short, such as protocol startup and protocol exit. This can use
suffix letters of `s', `m', `h', and `d' to mean seconds, minutes,
hours or days, with no suffix signifying seconds. Times can be added
through direct concatenation. For example, the value `5m30s'
signifies 5 minutes and 30 seconds.
The default value is 5 minutes.
This defines the response timeout for long operations, i.e., those
that are not short. Suffix letters can be used in the same manner as
with
short_timeout.
The default value is 2 hours.
This attribute identifies a TCP/IP port number, either directly as a
number, or as a name to be searched for in the
/etc/services
file. This port number will be used in connecting to the remote host.
The default is
smtp.
Use DNS resolution, if supported, to locate and use MX and A records
associated with the target host; without this option, the
gethostbyname() function is used to locate the address to use
for delivery. If the target host was matched with the bind
router driver, then MX and A records found by the bind router
will be used independent of the use_bind attribute.
If use_bind is specified, these attributes vary the behavior of
the tcpsmtp transport's DNS resolution. See the documentation
for the bind router for an explanation of these attributes.
The smtp driver attempts to connect immediately and deliver a single message. If access to the remote host is currently not possible, the driver will tell smail that delivery should be attempted at a later time.
An example of the use of the smtp driver is the entry:
# deliver using SMTP over TCP/IP to the remote host
tcpsmtp: -max_chars, -max_addrs, driver=smtp
If your site is on the Internet and gateways from the UUCP zone, it may be reasonable to set the strict attribute. Otherwise, this is probably not a good idea.
If the local attribute is set (see the generic transport attributes), then mail will be transmitted in a form that contains little reference to the transmitting host. This can be used within a local network to make all mail transmitted within the network look like local mail (i.e., local addresses will not be qualified with the domain name). This is often convenient in environments that use a central host for processing all mailing lists and user addresses, but where mail can originate and be delivered anywhere in the network, and where user names are consistent throughout the network.
When mail is transmitted outside of the local network, an smtp transport with the local attribute turned off will qualify any mail sent from anywhere inside the network.
The SMTP transport is also affected by the inet and uucp generic transport attributes. If inet is set, then sender and recipient addresses transmitted in the protocol envelope will strictly conform to the RFC821 and RFC1123 protocol specifications. However, route-addr addresses may be generated, despite the recommendations of RFC1123 against the practice. Note that networks connected completely by domain name servers will not result in generation of route-addr addresses, although they will be honored if received.
If the uucp transport attribute is set, then sender and recipient addresses will conform to the envelope specifications of RFC976, and will thus use !-style routes. Addresses transmitted to the remote host will consist only of ! and % operators. % operators will never be generated, but may be included if they were present in the original sender or recipient addresses.
If neither the uucp nor the inet attributes are specified, then an intermediate form will be used that nearly eliminates route-addr addresses. This form uses RFC976 !-style addresses when routing is necessary, but otherwise stays within the formal SMTP specification.
The smtp driver always sets the crlf and dots transport attributes.
The default internal configuration is defined in the source files config.h and default.c. The default director configuration uses:
The default router configuration uses:
The default transport configuration defines:
uusmtp
demand_uusmtp
Note that the uusmtp transports are not likely to be useful unless both the receiving host also uses Smail 3.1.
The uusmtp transport passes the -r option to uux, while the demand_uusmtp transport does not. Also, the uucp generic transport attribute is used by uusmtp and demand_uusmtp to transfer addresses in accordance with the RFC976 specification. This violates the RFC821 and RFC1123 specifications, but is none-the-less useful between sites operating in the UUCP zone.
inet_uusmtp
inet_demand_uusmtp
smtp
uucp_zone_smtp
inet_zone_smtp
The uucp_zone_smtp attribute has the uucp transport attribute set, causing transferred addresses to use !-style addresses, as specified in RFC976. This can often be useful when using SMTP within the UUCP zone, but is otherwise inappropriate.
The inet_zone_smtp attribute has the inet transport attribute set, causing transferred addresses to conform to the RFC821 and RFC1123 specifications for SMTP. This is necessary for correct operation with arbitrary nodes on the Internet. Both the uucp_zone_smtp and inet_zone_smtp attributes will handle generated routes (from paths files) correctly between nodes running Smail3.1. The inet_zone_smtp transport will use route-addr addresses for routing despite RFC1123's recommendations against such a practice. However, generated routes should never be necessary on the Internet.
The smtp transport is identical to either the uucp_zone_smtp transport or the inet_zone_smtp transport, depending upon local configuration information specified when the smail program is compiled. This depends upon the setting of the UUCP_ZONE attribute in the conf/EDITME file.
local_uux
local_demand
local_uusmtp
local_demand_uusmtp
local_smtp
There should be a way of specifying that different errors encountered by smail should result in different actions (i.e., mailing a message to the postmaster, storing a detailed error message in a file).